自動でS3バケットのパブリックアクセスを無効化する方法

Configルールと自動修復の機能を使用してS3のブロックパブリックアクセス設定を有効化します。設定が変更された場合は自動修復により、あるべき設定値に自動で修正されます。

#AWS Config

#AWS

森田桂介

2020.02.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS事業本部の森田です。

今回はConfigルールを用いて、アカウントレベルで自動的にS3のパブリックアクセスを無効化する設定を行います。

S3バケットをパブリックアクセス可能にすることはあまりないと思いますので、公開することが無いとわかっている場合は今回の設定を入れておくことで設定ミスなどで公開されてしまうリスクが軽減できます。

ブロックパブリックアクセス設定について

バケットを公開しないようにするために、S3のブロックパブリックアクセス設定を使用します。この設定はバケット単位、またはアカウントレベルで設定ができます。アカウントレベルで設定することにより、既存のバケット、これから作成するバケットのすべてでブロックパブリックアクセス設定が有効化されます。今回はアカウントレベルの設定を行います。

使用するConfigルール

実現方法はマネージドルールのs3-account-level-public-access-blocksを使用して設定が有効になっていない場合の検知を行います。検知した場合、修復アクションでSSM Automationを実行して強制的にブロックの設定に変更します。

必要なパブリックアクセスブロック設定がアカウントレベルから設定されているかどうかを確認します。出典: s3-account-level-public-access-blocks - AWS Config

やってみる

ブロックパブリックアクセスの確認

S3画面を開き、アカウントレベルのブロックパブリックアクセスを確認します。現在は下記のように有効になっていません。

設定レコーダーを有効にする

私自身ここの設定に不足があったため躓きました。下記スクリーンショットの「グローバルリソース（AWS IAM リソースなど）を含める」にチェックを入れていなかったためルールで検知できませんでした。下記のようにすべてのリソースの記録を取得するか、今回の要件だけだと「特定のリソースタイプを記録する」を選び、AWS S3 AccountPublicAccessBlockを選択しておいてください。アカウントレベルの設定ですので、グローバルリソースということですね。

余談ですが、対象リソースの記録がオフになっていると、正しく評価されない場合があるので注意してください。

設定レコーダーがオフになっているときのルールの評価

設定レコーダーをオフにすると、AWS Config ではリソースの設定変更の記録を停止します。これは以下のようにルールの評価ルールに影響します。

定期的トリガーのルールは、引き続き指定した間隔で評価が実行されます。

設定変更トリガーのルールでは、評価が実行されません。

両方のトリガータイプのルールでは、指定した間隔でのみ評価が実行されます。設定変更のルールでは評価が実行されません。

設定変更トリガーのルールのオンデマンド評価を実行すると、リソースの最後の知られている状態 (前回記録された設定項目) が評価されます。

AWS Config ルールのトリガーの指定 - AWS Config

SSM Automationドキュメントの作成

自動修復で使用するAutomationドキュメントを作成します。Systems Managerの画面を開き、ドキュメント → Create automationをクリックします。

コンテンツ → Editをクリックし、ドキュメント名とドキュメント本文を入力していきます。

ドキュメントは下記の内容になります。

description: >
  アカウントレベルでS3のブロックパブリックアクセスを有効化します。
schemaVersion: '0.3'
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    default: ""
mainSteps:
  - name: EnableS3AccountLevelPublicAccessBlocks
    action: 'aws:executeAwsApi'
    inputs:
      Service: s3control
      Api: PutPublicAccessBlock
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true
      AccountId: '{{ global:ACCOUNT_ID }}'

SSM Automationを実行するIAM Roleを作成

s3:PutAccountPublicAccessBlockだけ必要になります。下記のように作成します。

SSMがAssumeRoleできるように信頼します。

ルールの作成

AWS Config画面のルールから「ルールの追加」をクリックし、s3-account-level-public-access-blockを選択します。

下記のように変更し、保存します。

名前：任意
修復アクション：上記で作成したAutomationドキュメントを指定
自動修復：はい
AutomationAssumeRole：上記で作成したIAMロールのARN

確認

作成直後にルールを開くと評価中となっています。

しばらくするとルールに準拠していないことが検知されます。その後、修復アクションが実行されます。

修復アクションの実行履歴を確認してみます。Systems Manager画面から、自動化 → 実行履歴を選択します。

下記の通り作成したAutomationドキュメントが修復アクションとして実行されていることが確認できました。

次にS3の設定を見てみます。パブリックアクセスがブロックされています。

Configルールの画面に戻り、準拠となっていることが確認できました。

まとめ

S3バケットを設定ミスにより公開してしまっていた、という話はたまに聞くので、この設定を入れることによりリスクが軽減されるのではないでしょうか。そもそもIAMポリシーで変更できないようにしておくのがいいかと思いますが、セキュリティは何重にも防御を行うことが大切ですので、合わせて設定していただければと思います。

ちなみにGruadDutyも有効化していたのですが、S3バケットのパブリックアクセス設定を変更するとアラートが飛んできました。GuardDutyも有用なサービスですので、有効化を検討していただければと思います。

どなたかの参考になれば幸いです。